1. Field of the Invention
This invention relates to database drivers and more particularly relates to using database drivers to establish a reusable and reconfigurable model for fast and persistent connections within a trusted context.
2. Description of the Related Art
FIG. 1 depicts a conventional system 100 for allowing end users to access data through a data server. The conventional system 100 includes a conventional middleware server 102, a conventional data server 106, a database 108, and a network 104 connecting the middleware server 102 to the data server 106. End users (not shown) can connect to the middleware server 102, and thus the data server 106, through clients 110, and 112.
Under the popular three-tiered web model, a middleware server 102, such as an application server, at the middle tier is often used to authenticate client applications 110 and 112 and to handle connections to underlying data servers 106 through the use of database drivers. Traditionally, an end user logs onto the middleware server 102, and the middleware server 102 subsequently requests a connection with the data server 106. In order to accomplish this, the middleware server 102 may provide the data server 106 with some form of identification such as a user name and password. The data server 106 then validates the user name and password such that the middleware server 102 is authorized to connect to the conventional data server 106. Using such a connection, data may be accessed on the database 108 through the middleware server 102 and returned to the end user. After a transaction is complete, the connection may be terminated.
However, with regard to this type conventional database system 100, two major issues arise. First, every database access performed by the middleware server 102 requires authorization checking, which takes a significant time and significant processing capacity. Second, the database access under the authorization information provided by the middleware server 102 may actually be performed on behalf of the client application 110 or 112. Under this circumstance, the identity of the client application 110 or 112 may not be propagated to the data server 106, and consequently, there is a loss of end-user accountability.
Furthermore, because access to the database 108 is managed based upon the user identification of the middleware server 102, that middleware server user identification is granted all the privileges required for the actions of all of the end users connecting to the database 108 through the middleware server 102. This results in weakened security because every end user has access to the same set of privileges on the database 108. For example, all end users of the middleware server 102 may access the same data on the database 108 even though the end user themselves may not otherwise be authorized to access the data. Security for the database 108 is thereby weakened. Alternatively, each time a new end user accesses the database 108 through the middleware server 102, the connection between the middleware server 102 and the data server 106 is re-established based on the identification of the end user. Providing new connections for each end user ameliorates the weakening of security discussed above. However, overhead is greatly increased and performance suffers significantly.
Today, advanced database servers support trusted context technology, which enables the identity of the client application to be propagated, and to be used in related database accesses. U.S. Patent Application 2006/0143436 (hereinafter the “'436 application”) entitled “Method and system for providing and utilizing a network trusted context” discloses a method and system for establishing a trusted context and is herein incorporated by reference. A trusted context allows for the use of trusted connections which allow the identity of a client application 110 or 112 to be propagated to the data server 106 and to be used in related database accesses. The method and system disclosed in the '436 application comprise defining a plurality of trust attributes corresponding to a trusted context between the middleware server 102 and the data server 106 and validating the plurality of trust attributes against a plurality of attributes corresponding to the middleware server 102. The plurality of attributes is provided in a connection request. Then, a trusted context is established in response to the attributes being validated.
Although, trusted context technology provides for the use of trusted connections that can be reused without the need for re-authentication, existing database drivers lack needed interoperability with existing authentication mechanisms, such as the Kerberos mechanism and the DCE (Distributed Computing Environment) mechanism. Furthermore, currently available database drivers lack the interoperability to allow for quick configuration and re-configuration of a trusted connection to provide different types of connections such as a normal connection, a pooled connection, or even a distribution transaction connection. Thus, a need exists for a database driver that provides this type enhanced interoperability.